Distributed filesystem network security extension

ABSTRACT

A security protocol that dynamically implements enhanced mount security of a filesystem when access to sensitive files on a networked filesystem is requested. When the user of a client system attempts to access a specially-tagged sensitive file, the server hosting the filesystem executes a software code that terminates the current mount and re-configures the server ports to accept a re-mount from the client via a more secure port. The server re-configured server port is provided the IP address of the client and matches the IP address during the re-mount operation. The switch to a secure mount is completed in a seamless manner so that authorized users are allowed to access sensitive files without bogging down the server with costly encryption and other resource-intensive security features. No significant delay is experienced by the user, while the sensitive file is shielded from un-authorized capture during transmission to the client system.

BACKGROUND OF THE INVENTION

[0001] 1. Technical Field

[0002] The present invention relates in general to network systems andin particular to distributed filesystems. Still more particularly, thepresent invention relates to security features for access to distributedfilesystems.

[0003] 2. Description of the Related Art

[0004] In general purpose computing systems, such as those supportingversions of the Unix operating system (OS), applications may access datastored on disk drives by means of a set of operating system servicesincluding a filesystem. A filesystem may be employed by a computersystem to organize a large collection of files into individual files anddirectories of files and to map those files to storage devices such asdisks. Filesystems comprise two primary components, the programs thatcontrol the physical representation of the files and the filesthemselves that are stored on the disk.

[0005] In a distributed computing environment, a number of computingsystems can be interconnected by way of a communication network or othercoupling facility and can share files by way of a distributedfilesystem. A filesystem exporter is typically executed on the servernode (the computing system that controls access to the disk containingthe filesystem data), while a filesystem importer is typically executedon the client nodes (other computing systems utilized to access thefiles on the disk). Accesses to shared files by users on the clientnodes are referred to as “remote” accesses. Accesses to shared filesmade by users on the server node are referred to as “local” accesses.

[0006] The network filesystem is stored on a server or node of anetwork, and the server or node is accessible from client terminals(i.e., user computers) that are typically remotely linked to thenetwork. The actual link may be a wired link, as in a standardEthernet-based local area network (LAN) or a wireless link, such as aBluetooth Virtual Private Network (VPN). The process of accessing thefilesystem via the client terminals is referred to as “mounting afilesystem.” When a filesystem is mounted, the filesystem's controlprogram reads certain information from the disk concerning the layout offilesystem objects. From this information, the filesystem constructsdata structures known as “virtual filesystems” or Vfs's. Each time afile is opened, or made accessible, the filesystem creates a datastructure, referred to as a “vnode”, which is chained to the vfs.

[0007] Each vnode contains information about a given file and containsreferences to physical file system data structures. The physical filesystem data structures contain information such as the owner of thefile, the size of the file, the date and time of the file's creation andthe location of the blocks of the file on the disk. Filesystems includeinternal data, called meta-data, to manage files. Meta-data may includedata that indicates: where each data block of a file is stored; wherememory-modified versions of a file are stored; and the permissions andowners of a file.

[0008] With more and more companies using remote/network-accessibledistributed filesystems to electronically store and later retrievefiles/documents, including some with sensitive information, security ofdistributed filesystems is becoming increasingly important. The IPSecurity (IPSec) suite of standards was introduced and provides twoprimary security features: authentication and encryption. In otherwords, IPSec ensures that sending and receiving machines really are whatthey claim to be, and IPSec enables data to be scrambled in flight sothe data will be incomprehensible if intercepted.

[0009] Most systems thus require an authentication of the user duringthe initial mount, which typically includes verifying user-passwords,etc. However, password-protection and similar security measures arenotorious for being open to cracking and can easily be compromised, andthe industry has recognized that password-protected systems offer verylittle protection to sensitive files once general access to thefilesystem is obtained.

[0010] More advanced hackers also gain access to the files stored on thefilesystem by tapping into a transmission during an authorized mount andsimply copying the data as it is being transmitted from filesystem toclient system. This occurs because, with most password-protecteddistributed filesystems, once the several levels of security log-in(password verification, etc) are completed, the actual transmission ofthe files from the filesystem occurs in clear text. Thus, when thetransmission includes very sensitive data, additional security measuresare required to ensure that the clear text data is not available bysimply copying the file during transmission.

[0011] The ease at which the security of the sensitive information maybe compromised via this latter method depends to some extent on themedium being utilized by authorized users to mount/access thefilesystem. For example, wireless access/transmission is typically moreprone to eavesdropping and cracking that wire-full (wired) networkmedia. However, even the standard Ethernet can easily be breachedwithout detection, and thus the standard Ethernet is also an unsafeoption for routing sensitive data.

[0012] As mentioned above, the industry has responded to the growingneed for security on the transmission medium by imposing heavyencryption on all transmitted data during a mount of the filesystem.Currently, there are several encryption algorithms and standards (e.g.,wireless transport layer security) designed to provide security for thetransmissions between client system/node and the server hosting thefilesystem. Utilization of heavy encryption requires placing a heavyprocessing burden on the client system and the server for all traffic.The overall performance of the system is degraded, and significant costsare incurred by companies that wish to implement system-wide encryptionfor access to their filesystem. Encryption is built into thecommunication mechanisms and applied to all traffic between clientsystem and server although the majority of traffic may not require thatlevel of security (e.g., non-sensitive information/files).

[0013] The utilization of wireless systems to access filesystems isincreasing as companies provide remote access to users who may be mobileand wish to connect to the network remotely. Wireless connections are,however, more susceptible to cracking than wired connections. Somewireless users use WTLS, but this security feature is known to be arelatively weak level of security. One solution requires a VirtualPrivate Network (VPN) data encapsulation/encryption to access sensitivedata, even when the majority of clients are accessing the filesystem viatoken ring. This VPN data encapsulation would further negatively impactthe speed of the servers as they encrypt and decrypt all data.

[0014] It is also possible to configure VPNs or servers on a VPN torecognize IP addresses or subnets and only require encryption on certainsubnets. One problem with this solution is that the administrator of thedistributed filesystem server must have knowledge of every wireless nodethat is not within the network. If a wireless network is set up by anorganization within their department, the server administrator wouldneed to be made aware of the wireless network so that the subnet couldbe added to the VPN list of IP addresses.

[0015] In light of the foregoing, the present invention recognizes thatit would be desirable to have a method, system and data processingsystem that dynamically implements enhanced mount security when accessto sensitive files on a distributed filesystem is requested. A methodand system that would automatically provide a secure mount wheneversensitive file/data are about to be accessed during an ongoing sessionwould be a welcomed improvement. It would be further desirable if thesecure mount was completed in a seamless manner so that the authorizeduser receives access to the sensitive file without experiencing adisconnect and re-mount authentication process, while the sensitive fileis shielded from unauthorized capture by routing the sensitive file viathe more secure mount.

SUMMARY OF THE INVENTION

[0016] Disclosed is a method, system and computer program product thatdynamically implements enhanced mount security of a filesystem whenaccess to sensitive files on a networked filesystem is requested. Theclient system initiates a standard mount and authentication process foraccess to files of the filesystem. When the user of the client systemattempts to access a specially tagged sensitive file, the serverexecutes a software code that terminates the current mount. The serveris re-configured to route to a secure port any attempts to re-mount theserver from the IP address associated with the client. When a session isterminated by the server, the client system is programmed toautomatically attempt to re-mount the server. The server recognizes theIP address of the client during the re-mount operation and routes theclient to the secure port.

[0017] A secure mount is thus automatically provided whenever sensitivefiles/data are about to be accessed during an ongoing session that wasinitiated on a standard mount. Then routing via a secure mount iscompleted in a seamless manner so that the authorized user receivesaccess to the sensitive file without experiencing significant delay or avisible disconnect that requires user-initiated re-mount andauthentication processes. Meanwhile the sensitive file is shielded fromunauthorized capture by routing the sensitive file via the more securemount established.

[0018] The above as well as additional objectives, features, andadvantages of the present invention will become apparent in thefollowing detailed written description.

BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The novel features believed characteristic of the invention areset forth in the appended claims. The invention itself however, as wellas a preferred mode of use, further objects and advantages thereof, willbest be understood by reference to the following detailed description ofan illustrative embodiment when read in conjunction with theaccompanying drawings, wherein:

[0020]FIG. 1A is a block diagram of a data processing system withinwhich the features of the invention may be implemented;

[0021]FIG. 1B is a block diagram representation of the files within thefilesystem of FIG. 1A having a security tag indicating a required levelof security according to one embodiment of the invention;

[0022]FIG. 2 is a block diagram of a distributed network within whichfeatures of the invention may be implemented according to one embodimentof the invention;

[0023]FIG. 3A is a flow chart of the process by which a client isprovided access to sensitive files during access via a standard mountaccording to one embodiment of the invention;

[0024]FIGS. 3B and 3C are flow charts of the processes by which a servermonitors and controls client requests for access to sensitive files toensure that access to those files is routed via a secure channelaccording to one embodiment of the invention; and

[0025]FIG. 4 is a block diagram illustrating logic components forseamlessly completing a switch of a client session on a filesystem froma standard, non-secured channel to a secured channel during a singlecontinuing session in accordance with one embodiment of the invention.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENT(S)

[0026] With reference now to the figures and in particular withreference to FIG. 1A, there is illustrated a block diagram of a computersystem, which may be utilized as either a server hosting the distributedfilesystem or a client system utilized to mount the server at which thedistributed filesystem is hosted. Computer system 100 comprisesprocessor 102 and memory 104 connected via system bus/interconnect 110.Computer system 100 also comprises Input/Output (I/O) Channel Controller(CC) 109, which is coupled to interconnect 110. I/0 CC 109 providesconnection to I/O devices 106, including Redundant Array of Disk (RAID)114. RAID 114 stores instructions and data that are loaded to memory asneeded by the applications being executed by the processor. According tothe illustrative embodiment, RAID 114 provides the storage media for theplurality of files that constitute filesystem 112.

[0027] Computer system 100 further comprises network connection devices108, which may include wireline modem, wireless modem, and Ethernetcard, among others. Access to and from I/O devices 106 and networkconnection devices 108 are routed through I/O channel controller (I/OCC)109, which includes logic for completing the automatic re-establishmentof a mount to/from computer system 100 via a “secure” path/channel/portwhen required, as further described below.

[0028] Computer system 100 includes operating system (OS) 122,filesystem software application 124, mount code 125 and DFNSE 126.Filesystem software application 124 provides the basic accessing,maintaining, and updating of filesystem 112, when computer system 100 isbeing utilized to host a filesystem 112.

[0029] When within a client system, filesystem software application 124includes client version of mount code 125 for completing a mount andautomatic re-mount of the server hosting the filesystem. In theillustrative embodiment, the automatic remount process is implemented bythe client system whenever an established mount with the server isdisrupted/lost without the client having completed an unmount of theserver. In the described embodiment, the server may issue a FYN commandto terminate a current mount and thus force the client to initiate are-mount of the server. The FYN command is issued in response to accessto particular files that require special security protections, as willbe explained in greater detail below.

[0030] Returning to FIG. 1A, and the description of filesystem softwareapplication 124, when executed within a server, filesystem softwareapplication 124 includes code for receiving, maintaining, and verifyingcredential information of various users and client systems, code formaintaining filesystem 112 and code for selectively initiating asecurity software and associated response, called Distributed FilesystemNetwork Security Extension (DFNSE) 126. DFNSE 126 provides the backboneof the inventive features herein and the execution of DFNSE 126 on aserver is described below with reference to FIGS. 3A-3C and 4A. At abasic level, DFNSE 126 determines what level of security access ispermitted/authorized for specific files of the filesystem 112 and whento initiate the enhanced security measures of the invention.

[0031] With reference now to FIG. 2, there is illustrated an examplenetwork comprising multiple interconnected computer systems, which maybe similarly configured to computer systems 100 of FIG. 1 that areadvantageously utilized to provide either the server or clientfunctionality for respectively hosting or accessing a distributedfilesystem. Network 200 comprises a distributed filesystem 202 hosted onthree (or more) interconnected servers 203. Network 200 also comprises aplurality of client systems 201 connected to distributed filesystem 202via a network backbone 210. Network backbone 210 comprises one or morenetwork-connectivity systems (or sub-networks) that may be configuredaccording to network protocols such as Ethernet or TokenRing. Thesesub-networks may be, for example, wire-line or wireless local areanetworks (LAN) or a wide area network (WAN), such as the Internet.Additionally, sub-networks may include fiber optic network as well.

[0032] Distributed filesystem 202 is directly coupled to networkbackbone 210 via one or more ports (not shown) on at least one of theservers 203. Client systems 201 may be either directly coupled to thenetwork backbone (wireline) or communicatively connected via a wirelessmedium illustrated by wireless antenna 207. Client systems 201 accessthe distributed filesystem 202 via one of the various available mediautilizing one of the various network configurations, each one having adifferent level of susceptibility to cracking. Thus, client system 201may access and mount filesystem 202 via a non-secure wireless network227, or client system 201 may mount filesystem 202 utilizing a securefiber-optic network 225. For simplicity of describing the invention, thewireless network 227 will be assume to be a standard, non-secure networkwithout encryption, while the fiber-optic network 225 is assumed to be aspecial, secured connection with encryption. Each connection is routedvia a different one of the ports available to the server 203 at whichthe mount of filesystem 202 is supported.

[0033]FIG. 1B illustrates a block diagram representation of filesystem202 with a more detailed delineation of the files that comprisefilesystem 202. As illustrated, filesystem 202 comprises a control block131 and a plurality of files 132a-n, each of which includes a metadatatag 112 with header/identifier field 334 and security field 336.Header/ID field 334 contains information about the file ID and the userswho have access to the file. Security field is a single bit field, whichindicates the level of security attributable to that file andconsequently the type of user-access permitted. According to theillustrative embodiment, certain files that require highest levels ofsecurity and which are restricted to being accessed solely on a securedmount (e.g., files 1 and 3) are tagged with “1” in the security field336 of their respective metadata. Other files not so tagged (i.e.,tagged with a 0) are normal (e.g., file 2) and may be access by anyauthorized user without a special secured mount.

[0034] As mentioned above, the invention introduces an enhanced securitymechanism, which, in the illustrative embodiment, is referred to asDFNSE (Distributed Filesystem Network Security Extension). With DFNSE,the filesystem server is able to infer from the file permissionsassociated with a file or directory the level of network security thatis required when providing access to the file by particular users. DFNSEis a server-level filesystem security enforcement application and/orprocedure. Accordingly, with DFNSE, only the server is required to haveknowledge of the networks connections or adapters being utilized by theserver.

[0035] Specific hardware, logic and software components are providedwithin each server capable of providing a mount to the filesystem toimplement DFNSE. FIG. 4 is a block diagram illustrating some of thesecomponents. As illustrated in FIG. 4, server 203 may be provided withtwo Ethernet network adapters (or ports): en0 403, which is secure, anden1 405, which is not secure. In one embodiment, the network topologybehind these adapters is consistent. That is, the sub-network selecteditself provides the security and the server is able to dynamicallyselect between sub-networks based on the level of security required. Inanother embodiment, additional encryption or other security features areprovided with the secure adapter, en0 403.

[0036] En0 403 connects to a fiber network 225 that is utilized to routeall sensitive data, while en1 405 connects to a standard Ethernet-basedwired network 221 and is utilized for routing all other (non-sensitive)data communication. En1 405 is the default port for mounting thefilesystem's server. The exemplary embodiment assumes that the ease atwhich the standard Ethernet can be breached without detection makes theEthernet an unsafe option for routing sensitive data. During a mount ofthe filesystem, the server, which has detail knowledge of the filepermissions 334 and security level 336 for each file tracks user accessand determines when to force the client to switch over to the securenetwork based on the file permissions in place for the files beingaccessed. According to the illustrative embodiment, the network topologyis consistent for both the secure and non-secure routes so that noadditional hardware and/or routing protocol upgrades are required toaccount for different topologies during the switch from non-secured tosecured sub-network.

[0037] Server 203 of FIG. 4 also includes a mount controller 407, whichperforms conventional mount support and unmount operations forfilesystem 202 as well as re-mount configuration in accordance with thefeatures of the present invention. Mount controller 407 includes DFNSE126 and is preferably embodied as software code executing on server 203.DFNSE 126 operates to trigger mount controller 407 to route a requestfor a mount via either standard port, En1 405, or secured port, En0 403.Server 203 also includes encryption module 409 utilized in conjunctionwith DFNSE 126 and En0 403, when encryption is implemented on securedport.

[0038] During filesystem access, when a request for access to sensitiveoperation is received at server 203, mount controller 407 marks theclient's IP address as one needing access to sensitive data. Server 203then breaks the current connection, (i.e., the server sends a FYN to theclient). The client automatically attempts to reconnect, and mountcontroller 407 recognizes the client IP address during the re-mount. Theclient's session is then directed to a secure SSL port. Thus, whileprimary access is provided via the standard port, access is dynamicallyswitched to the SSL secure port when access to sensitive data/files isrequired.

[0039] Turning now to FIG. 3B, there is illustrated a flow chart of theprocess by which the software-implemented DFNSE security features areimplemented within the above hardware/logic configuration of the serverhosting the filesystem. The process begins with a standard mount requestreceived at the standard port of the server from a client as shown atblock 321. The user is prompted for authentication data (password, etc.)and the client system's IP address is retrieved from the data packet asindicated at block 323. A session is opened on the standard port andboth the IP address and the user's authentication data are stored withina parameter file linked to the particular session as shown at block 325.Once the session is established, i.e., server logic associated withaccess permissions, etc., monitors the user's interaction as shown atblock 327 and a determination made at block 329 whether the user isrequesting access to a sensitive file.

[0040] The server that is satisfying a clients request for a file isprogrammed with the authorization/credentials of the user on the remoteclient and the permissions of the file being accessed. If the file beingaccessed is not sensitive, regular access is provided to the user on thestandard port as shown at block 331. However, when the file beingrequested by the client is a sensitive file that requires a more securechannel before access can be granted, a next determination is made atblock 333 whether the user has proper access permission to access thefile. If the user does not have proper access permission the request isdenied as shown at block 335. If, however, the user's credentialsindicates the user has permission to access the particular file, theDFNSE security protocol is activated as shown at block 337. Activationof DFNSE causes the server to force an unmount of the client by issuinga FYN to the client and concurrently configuring a more secure port toaccept the re-mount from the client having the IP address saved with thesession parameters. The server then provides secured access to the filevia the secured port as shown at block 339.

[0041]FIG. 3A is a flow chart of the processes involved in theimplementation of the invention primarily from the perspective of theuser/client system. The process begins when a user (via the clientsystem) first mounts a server hosting the filesystem as illustrated atblock 302 and requests access to the filesystem as shown at block 304.When the client initially mounts the NFS filesystem, the mount iscompleted over a standard TCP connection by default. For example, theconnection may be to the well known NFS port of 2048. The server has alistening socket bound to this port and operates according to thestandard (non-secure) protocol. Notably, in the illustrative embodiment,the standard protocol is enhanced by the DFNSE protocol, which isimplemented when access to sensitive files are requested.

[0042] When a connection is requested from the client, the listeningsocket of the server basically duplicates itself and bounds theconnection to the remote client. The listening socket then remains opento handle other connection requests. Authentication of the client isinitiated as shown at block 306 and a determination made at block 308whether the client's authentication was successful. If the client/userauthentication process is un-successful, access to the filesystem isdenied and the mount is disconnected as shown at block 310. Then theprocess ends as indicated at block 311. Otherwise, a session is openedand the user is provided access to the filesystem as shown at block 309.

[0043] The client system monitors the connection for disconnects asshown at block 312 and determines as indicated at block 314 whether theconnection becomes un-responsive or is pre-maturely broken at the serverside (i.e., ideally when a server issued FYN is received). When theconnection becomes unresponsive or broken, the client initiates are-mount that is routed to the port indicated by the server as shown atblock 316.

[0044] Notably, re-connection in response to a server-initiated dismountis directed on a secure port at the server, although the actual port maybe unknown to the client system. Utilizing the security protocols ofDFNSE and based on the knowledge of which port is secure and whether thesession requires a secure port, the server is able to request that theclient re-mount over a secure port. For example, the client may be madeto re-mount utilizing a port running Secure Socket Layer. Notably, nouser-action is required to complete the re-mount and port-switchingprocedures. The monitoring for server-side unmount and subsequentre-mount all occur as background processes at the client system, and theuser (client) is not made aware of the switch to a more secure port.

[0045] A more detailed account of the internal processing required forre-routing via a more secure port at the server side is illustrated bythe flow chart of FIG. 3C. The process begins when access to a sensitivefile is identified by DFNSE as shown at block 351. The server checks thecurrent port security as indicated at block 352. A determination is madeat block 354 whether the current port security is sufficient foraccessing the requested file (depending on how sensitive the file is,which is deduced by reading the security bit of the file in theillustrative embodiment). If the current port security is sufficient foraccessing the requested file, the access is provided as shown at block356.

[0046] In one alternate embodiment, the remount function may beselectively automated and the process would require a next determinationwhether the feature for automatic remount is enabled. With thisalternate embodiment, if the automatic remount capability is notenabled, the user will actually be prompted to remount via a securemount.

[0047] Returning to the illustrated embodiment of FIG. 3C, when the portsecurity is insufficient, the server responds by selecting a more secureport (e.g., En0) for the session as shown at block 358. The server takesa snapshot of the authentication and mount parameters of the session,including the client's IP address, and transfers these parameters to thecontrol logic of the more secure port as depicted at block 360. Thetransfer occurs with very little latency and the more secure port isthus automatically configured to receive a re-mount from that client andcontinue supporting the session in progress. After the secure port hasbeen configured, the corresponding port number is given to the mountcontroller along with the IP address of the client. The serverterminates the mount on the first standard port and re-establishes thesession via the more secure port when a re-mount is received from theclient as shown at block 362.

[0048] Notably, in response to the server terminating the initial mount,the client initiates the re-mount which is directed by the user to thesecond, secured link. This re-establishes the initial session of theclient but via the second port. Re-establishing the connection involveschecking the clients IP address and matching it to the port that is setup to receive the connection from that IP address. The entire processoccurs in the background and thus a seamless switching of ports iscompleted from the user's perspective.

[0049] In one alternate embodiment, the level of security attributableto a particular file is determined by the users (or selected clientsystems) that are provided access to the particular file. Thus, if fileaccess permissions are restricted to filesystem administrators only,then the security level is high, while file access permission given toregular employees indicates a relatively low level of security required.Determination of the security level for a file is completed when theuser initially creates the file and assigns the access permission tothat file. Once the file is placed within the filesystem, the fileautomatically inherits the network security protection that is in place.With this implementation, existing file permissions on files within thefilesystem (e.g., UNIX-rwx,rwx,rwx for user, group, other) fold into thesecurity model provided herein without requiring extensive systemadministration and configuration. Thus, the present invention eliminatesthe need for re-configuring existing filesystems on a per file basis.With the invention, there is also no requirement to move sensitive filesto a secure server.

[0050] While the invention has been particularly shown and describedwith reference to a preferred embodiment, it will be understood by thoseskilled in the art that various changes in form and detail may be madetherein without departing from the spirit and scope of the invention.For example, although described with specific reference to NFS, thepresent invention is also applicable to DFS or AFS and other similarprotocol.

What is claimed is:
 1. In a data processing system comprising (1) astorage medium on which is stored at least a first having a presetaccess permission, (2) at least a first standard port and a secondsecure port for connecting said data processing system to externalclient systems, and (3) logic for selectively routing transmission ofsaid at least one file via said first port and said second port, amethod for providing security for transmission of said at least onefile, said method comprising: responsive to a request for access to saidfirst file by said external client system, checking said preset accesspermission of said first file; and when said preset access permission ofsaid first file indicates secured access is required for said firstfile, dynamically routing a transmission of said first file to externalclient system via said second port.
 2. The method of claim 1, furthercomprising: routing said transmission of said first file via said firststandard port when said preset access permission indicates a regularaccess is sufficient.
 3. The method of claim 1, further comprising:enabling a first mount of said data processing system via said firststandard port; and enabling a second mount of said data processingsystem via said second secure port only when said first file requiressecured access.
 4. The method of claim 1, wherein said data processingsystem further comprises an encryption module associated with saidsecond secured port, said dynamic routing step comprising: firstencrypting said first file utilizing said encryption module.
 5. Themethod of claim 1, wherein said data processing system furtherreconfiguration logic for configuring said first standard port and saidsecond secured port for supporting a mount by said client system, saiddynamic routing step comprising: first configuring said second secureport to support a remount operation received from said client system;terminating a current mount on said first standard port with said clientsystem; and storing session parameters of said current mount to enableseamless continuation of said session on said second secure port.
 6. Themethod of claim 5, wherein said configuring and storing step includes:retrieving an IP address of said client system; placing said IP addressin a configuration of said second secure port, wherein said secondsecure port automatically recognizes a remount operation from saidclient system and re-establishes the session with said client system. 7.The method of claim 1, wherein said preset access permission is a bitwithin metadata linked to said first file and said method furthercomprises reading a value of said bit to evaluate whether said firstfile requires secure access.
 8. The method of claim 1, wherein saidpreset access permission includes an identification of which specificusers are permitted to access said first file via a secured access, saidmethod further comprising: comparing a user of said client system withsaid specific users with permission to access said file; and when saiduser is one of said specific users, automatically initiating are-routing of a transmission of said first file via said second secureport.
 9. The method of claim 1, wherein said first standard portconnects to said client system via a first unsecured network and saidsecond secure port connects to said client system via a second securednetwork.
 10. The method of claim 1, wherein: said data processing systemis a server within a network having a first subnet connecting said firststandard port to said client system and a second subnet connecting saidsecond secure port to said client system; said first file is storedwithin a filesystem; said checking step includes accessing saidfilesystem and locating said first file; and said routing step includestransmitting said file via said second subnet when said file requiressecure access and transmitting said first file via said first subnetwhen said first file does not require secure access.
 11. In a dataprocessing system comprising (1) a storage medium on which is stored atleast a first having a preset access permission, (2) at least a firststandard port and a second secure port for connecting said dataprocessing system to external client systems, and (3) logic forselectively routing transmission of said at least one file via saidfirst port and said second port, a system for providing security fortransmission of said at least one file, said system comprising: logic,responsive to a request for access to said first file by said externalclient system, for checking said preset access permission of said firstfile; and when said preset access permission of said first fileindicates secured access is required for said first file, logic fordynamically routing a transmission of said first file to external clientsystem via said second port.
 12. The system of claim 11, furthercomprising: logic for routing said transmission of said first file viasaid first standard port when said preset access permission indicates aregular access is sufficient.
 13. The system of claim 11, furthercomprising: logic for enabling a first mount of said data processingsystem via said first standard port; and logic for enabling a secondmount of said data processing system via said second secure port onlywhen said first file requires secured access.
 14. The system of claim11, wherein said data processing system further comprises an encryptionmodule associated with said second secured port, said logic fordynamically routing comprising: logic for first encrypting said firstfile utilizing said encryption module.
 15. The system of claim 11,wherein said data processing system further reconfiguration logic forconfiguring said first standard port and said second secured port forsupporting a mount by said client system, said logic for dynamicallyrouting comprising: logic for first configuring said second secure portto support a remount operation received from said client system; logicfor terminating a current mount on said first standard port with saidclient system; and logic for storing session parameters of said currentmount to enable seamless continuation of said session on said secondsecure port.
 16. The system of claim 15, wherein said configuring andstoring step includes: logic for retrieving an IP address of said clientsystem; logic for placing said IP address in a configuration of saidsecond secure port, wherein said second secure port automaticallyrecognizes a remount operation from said client system andre-establishes the session with said client system.
 17. The system ofclaim 11, wherein said preset access permission is a bit within metadatalinked to said first file and said system further comprises reading avalue of said bit to evaluate whether said first file requires secureaccess.
 18. The system of claim 11, wherein said preset accesspermission includes an identification of which specific users arepermitted to access said first file via a secured access, said systemfurther comprising: logic for comparing a user of said client systemwith said specific users with permission to access said file; and whensaid user is one of said specific users, logic for automaticallyinitiating a re-routing of a transmission of said first file via saidsecond secure port.
 19. The system of claim 11, wherein said firststandard port connects to said client system via a first unsecurednetwork and said second secure port connects to said client system via asecond secured network.
 20. The system of claim 11, wherein: said dataprocessing system is a server within a network having a first subnetconnecting said first standard port to said client system and a secondsubnet connecting said second secure port to said client system; saidfirst file is stored within a filesystem; said logic for checkingincludes means for accessing said filesystem and locating said firstfile; and said logic for routing includes means for transmitting saidfile via said second subnet when said file requires secure access andtransmitting said first file via said first subnet when said first filedoes not require secure access.
 21. In a network comprising (1) a serverhosting a filesystem and having at least a first standard port and asecond secure port, (2) a client, and (3) a plurality of transmissionsubnets for linking said server and said client, wherein said pluralityof transmission subnets include a first standard subnet and a secondsecure subnet, a filesystem access control mechanism comprising: logic,responsive to a request for access to said first file by said externalclient system, for checking said preset access permission of said firstfile; and when said preset access permission of said first fileindicates secured access is required for said first file, logic fordynamically routing a transmission of said first file to external clientsystem via said second port.
 22. The filesystem access control mechanismof claim 21, further comprising: logic for routing said transmission ofsaid first file via said first standard port when said preset accesspermission indicates a regular access is sufficient.
 23. The filesystemaccess control mechanism of claim 21, further comprising: logic forenabling a first mount of said data processing system via said firststandard port; and logic for enabling a second mount of said dataprocessing system via said second secure port only when said first filerequires secured access.
 24. The filesystem access control mechanism ofclaim 21, wherein said data processing system further comprises anencryption module associated with said second secured port, said logicfor dynamically routing comprising: logic for first encrypting saidfirst file utilizing said encryption module.
 25. The filesystem accesscontrol mechanism of claim 21, wherein said data processing systemfurther reconfiguration logic for configuring said first standard portand said second secured port for supporting a mount by said clientsystem, said logic for dynamically routing comprising: logic for firstconfiguring said second secure port to support a remount operationreceived from said client system; logic for terminating a current mounton said first standard port with said client system; and logic forstoring session parameters of said current mount to enable seamlesscontinuation of said session on said second secure port.
 26. Thefilesystem access control mechanism of claim 25, wherein saidconfiguring and storing step includes: logic for retrieving an IPaddress of said client system; logic for placing said IP address in aconfiguration of said second secure port, wherein said second secureport automatically recognizes a remount operation from said clientsystem and re-establishes the session with said client system.
 27. Thefilesystem access control mechanism of claim 21, wherein said presetaccess permission is a bit within metadata linked to said first file andsaid system further comprises reading a value of said bit to evaluatewhether said first file requires secure access.
 28. The filesystemaccess control mechanism of claim 21, wherein said preset accesspermission includes an identification of which specific users arepermitted to access said first file via a secured access, said systemfurther comprising: logic for comparing a user of said client systemwith said specific users with permission to access said file; and whensaid user is one of said specific users, logic for automaticallyinitiating a re-routing of a transmission of said first file via saidsecond secure port.
 29. The filesystem access control mechanism of claim21, wherein said first standard port connects to said client system viaa first unsecured network and said second secure port connects to saidclient system via a second secured network.
 30. The filesystem accesscontrol mechanism of claim 21, wherein: said data processing system is aserver within a network having a first subnet connecting said firststandard port to said client system and a second subnet connecting saidsecond secure port to said client system; said first file is storedwithin a filesystem; said logic for checking includes means foraccessing said filesystem and locating said first file; and said logicfor routing includes means for transmitting said file via said secondsubnet when said file requires secure access and transmitting said firstfile via said first subnet when said first file does not require secureaccess.